HandleCounterRate

do we expect this will work fine with updowncounter? I mean with values that increase and decrease?

@noahfalk

I expect functionally it will work, however thinking about it and talking it over with James Newton-King recently I'm not so sure it is the behavior users are going to want. I feel bad because I reviewed the earlier change to MetricsEventSource and ideally I would have spotted it at that earlier point rather than now. Definitely my bad :(

Although Counter and UpDownCounter officially only differ in whether they promise monotonicity, in practice I think the reason most people care is because Counter tends to keep going up and the rate of change is very relevant whereas UpDownCounter tends to stay in a fixed range and the absolute value is more important. For example a common use of UpDownCounter would be measuring the size of a cache or a queue. Users probably care much more that their queue has 1200 items in it rather than that it has 14 items less than it did 10 seconds ago.

So ideally my current goal would be to do:

1. Report the absolute value in addition to the rate of change in MetricsEventSource for Counters, ObservableCounter, UpDownCounter, and ObservableUpDownCounter
2. Make UpDownCounters + ObservableUpDownCounter report absolute value rather than rate-of-change in the tools

@kkeirstead - I know this is probably coming as a bit of a surprise, very sorry about that! If you felt you had the time to tackle those changes that would be awesome but if not we can chat and figure out another plan.

Gotcha, no problem - I can look into doing that. In the meantime I'll close this PR so it's not sitting here stale, and I'll open an updated one after making the other changes in MetricsEventSource

Thanks! 👍